Don't recompile git deps so frequently
authorAlex Crichton <alex@alexcrichton.com>
Wed, 10 Sep 2014 14:26:42 +0000 (07:26 -0700)
committerAlex Crichton <alex@alexcrichton.com>
Wed, 10 Sep 2014 14:26:42 +0000 (07:26 -0700)
commitc0127391bf789d61c4cf6c546e1500930e6cff2e
treeb21a35bb8a0d862c80fc0010c97ffd66e27a2698
parentef959038b7eee8ee0c83f4b57ed662c01c477bff
Don't recompile git deps so frequently

The previous logic for recompiling any dependency was almost entirely based on
the mtimes of the relevant input files. This isn't quite what's desired for git
and registry dependencies because the mtime could be fluctuating while the files
aren't changing. For example:

1. Project A checks out git repo C at revision C1
2. Project A builds, records mtimes of C
3. Project B checks out git repo C at revision C2
4. Project B builds, records new mtimes of C
5. Project A is rebuilt, rebuilding C b/c mtimes are different

In step 5 here C should not be rebuilt because the revision didn't actually
change.

This commit alters git/registry dependencies to completely bypass the --dep-info
emitted and only rely on the git/registry source to inform what the fingerprint
is. This is the revision/version, respectively, and should be all that's
necessary to track changes to the repo and trigger a rebuild.
src/cargo/ops/cargo_rustc/fingerprint.rs
tests/test_cargo_compile_git_deps.rs